[アップデート]Security Hub Automation Rules が利用できるようになりました #AWSreInforce

[アップデート]Security Hub Automation Rules が利用できるようになりました #AWSreInforce

マネージドで Security Hub の自動抑制ができるようになりました!
Clock Icon2023.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

枡川です。
アナハイムで AWS re:Inforce 2023 開催中ですね!
様々なアップデートが発表されていますが、 Security Hub でも新機能として Automation Rules が利用できるようになりました。

この機能を利用することで、条件を満たした findings のステータスを変更したり、重要度を変更したりすることが可能になります。
特定のリソースは自動で抑制したり、特定アカウントでは重要度を上げたりといった環境に合わせた細かな調整を実施できるので Security Hub をより便利に利用できるようになりました。

※ 正確に言うとこれまでも自動化自体は可能でしたが、Lambda や EventBridge Rule を利用しての作り込みが必要でした。今回のアップデートにより、下記のようなソリューションを実装しなくても Security Hub の機能として利用できるようになりました。

特定アカウントで Severity を変えてみた

早速使ってみます。
まずは、マネジメントコンソールからルールの作成をクリックします。

ルールを作成する際は条件自動アクション(条件に一致した際に行う操作)を指定します。
この際、あらかじめ定義されているテンプレートを元にルールを作成する方法と最初から独自のルールを定義する方法から選択することができます。

現在利用可能なテンプレートは下記です。

  • Elevate severity of findings that relate to important resources
  • Suppress informational findings
  • Elevate severity of findings that relate to resources in production accounts

テンプレートから作成してもすべての項目を変更できるので、積極的に活用していくと良いかと思います。
Security Hub の新規失敗ルールを指定するだけでも自分で記載すると少し面倒なので、Elevate severity of findings that relate to resources in production accounts あたりを元に条件や自動アクションを変更した方が楽に設定できると思います。

今回は Elevate severity of findings that relate to resources in production accounts を使って、特定アカウントで発生した Severity が HIGH の findings を CRITICAL に変更するルールを設定してみました。
条件はほぼそのままで、AwsAccountId として、自分の AWS アカウントに既に集約済みの AWS アカウント ID を指定します。
条件としてリソース名やリソースタイプを指定することも利用できますが、マルチアカウント戦略をとっていると環境ごとのセキュリティレベルを反映しやすいですね。

自動アクションの欄ではワークフローステータスや重要度等を変更できます。
変更しない箇所は None と設定しておく必要があります。
注 - オプションと記載されている部分もかなり重要で、こちらに記載した内容は Security Hub 内で Note として確認することが可能です。

ルールを作成した後、[S3.8] S3 Block Public Access setting should be enabled at the bucket level を検出させました。
本来、HIGH である findings が CRITIACAL として表示されています。

変更された findings には Automation Rules によって変更されたことがわかる形で Note が付与されます。
ルールを設定した理由を注 - オプションにきちんと書くことで、後で経緯を追いやすくなるので積極的に利用していきましょう。
ちなみに findings の JSON を確認すると、元々の Severity は Severity > Original として保持された上で、 Severity > Label として変更後の内容が登録されています。

注意点として、あくまで findings の内容が書き換わるだけでコントロール自体の Severity は変わらないです。
なので、 Security Hub のコンソールから確認するだけだとそこまで違いを感じないかもしれないです。(下図のように、コントロールを対象とした検索には影響を与えません)

Security Hub Insights で Severity ごとのダッシュボードを構築していたりする場合はうまく活用することで大きなメリットがあると思います。

自動抑制を設定してみた

次に特定リソースごとに自動で抑制するルールを作ってみました。
いろいろな使い方が考えられると思いますが、今回は特定の名前のバケットについて、[S3.9] S3 bucket server access logging should be enabledを抑制しようと思いました。
本コントロールは S3 server sccess log を有効化しているか確認可能なコントロールですが、全ての S3 バケットについてチェックされるため、S3 server access log の出力先になっていてもチェックの対象になります。
server Access log 保管用バケットの server access log 設定は過剰に思えるため、抑制したいタイミングも多かったかと思います。
今回はバケット名のプレフィクスを指定して自動抑制しました。
ResourceId として S3 の ARN を参照でき、完全一致やプレフィクス等を利用して条件を設定することができます。
(Tag 等で制御できたら便利かと思いましたが、Security Hub 側から Tag を確認できなかったので諦めました。)
条件として使える項目は下記ページにまとまっております。
Automation rules

自動アクションでワークフローステータスを SUPPRESSED に設定します。

条件に一致する検出結果のプレビューを確認することで設定したルールの対象となる findings を確認可能です。
細かいルールを設定する際は便利に利用できるかと思います。
(一覧に表示されているリソースに対して、ルール作成後すぐに自動アクションが適用されるわけではないです。次に Security Hub が評価するタイミングで自動アクションが適用されます。)

こちらを設定した後に、masukawa-server-access-bucket2 という名前でバケットを作成すると、Note が付与された状態で自動で抑制されました。

自動でやってくれるのは便利ですし、マネジメントコンソールから設定できない Note が勝手に付与されるのは最高ですね!

料金について

ap-northeast-1 での利用料金は下記です。
100 万評価まで無料なので、よほど大規模な環境で無ければ気軽に利用検討を始めることができると思います。

Volume of rule evaluations Price
First one million rule evaluations / month Free
Next 99 million rule evaluations / month $0.00000015 per evaluation
Next 900 million rule evaluations / month $0.000000075 per evaluation
Over 1,000 million rule evaluations / month $0.000000023 per evaluation

AWS Security Hub pricing

その他

  • 集約している場合は集約先アカウントでのみ利用可能な機能となります。集約元アカウントでは、左側のタブにも表示されなくなります。
  • ルールは 100 個まで定義可能です。
    • 上限に達する機会は多くないかと思いますが、コントロール無効化で良い場面でもこちらの機能を利用していると上限に抵触するかもしれないので、頭に入れておくと良いかと思います。
  • 他サービスから Security Hub に取り込んだ findings についても Automation Rules を適用可能です。
  • コントロール無効化の代わりとして Automation Rules による自動抑制を使うと、チェックは実施されないのに課金のみ発生する状態となるためにコストの観点から望ましくないです。
    • コントロール無効化で問題無い場合はそちらを検討しましょう。

If you want Security Hub to stop generating findings for a specific control, we recommend disabling the control instead of using an automation rule. When you disable a control, Security Hub stops running security checks on it and stops generating findings for it, so you won't incur charges for that control. We recommend using automation rules to change the values of specific ASFF fields for findings that match defined criteria. For more information about disabling controls, see Enabling and disabling controls in all standards.
Automation rules

さいごに

自動抑制機能を渇望していた人も多いのでは無いでしょうか?
幅広いことができると思うので、是非試してみて下さい!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.